Organizing ActiveBatch Objects

As you look through the ActiveBatch manuals and learn about all the various ActiveBatch objects that can be created, a question you will ultimately need to answer is “How do I best organize all the related objects that my business application needs?” This section will help you answer that question using best practices.

 

It is recommended that you place all the objects your Plans and Jobs may need within an organizational Plan or Folder. This has several benefits other than organization. First, if you ever need to migrate objects, moving the Plan and/or Folder with everything contained is much simpler and less prone to error than migrating each object individually (which can be further problematic when objects have dependencies). Second, when testing, you can always delete the Plan or Folder and know that everything inside the object will also be deleted. Next, add Jobs to Plans with the intent on triggering the Plan. Plans are triggerable, Folders are not.

 

 

In the image above, you can see the Folder named UsersGuideCaseStudies. In this Folder, a Folder named Objects contains the non-executing objects. By ‘non-executing’ we mean those objects that are not executed (like a Plan or Job). Therefore, non-executing objects are User Accounts, Queues, Schedules, Alerts, etc. By adopting this convention as a Best Practice, it becomes very simple to find objects regardless of the application. In general, keep the non-executing (shared) objects "close" to the Jobs and Plans that are using them. In the above example, the non-execution objects are stored in the Objects Folder, and the (4) Plans are using some or all of the objects stored there.

 

The four (4) Plans named CaseStudy1, 2, 3 and 4 are meant to be triggered and consist of other nested Plans and/or Jobs. ActiveBatch supports the referencing of an object anywhere within the namespace (assuming, of course, your security permits that access). For example:

 

 

Observe the path specification to “Server1”. Clicking on the Submission Queue dropdown would reveal the navigation tree for the currently connected Job Scheduler. Within this tree you could select any Queue (assuming the above example) within your system. The point we are making is that Folders and/or Plans do not have to be isolated.

 

For those users who do want a level of isolation, Virtual Root is the facility you will want to examine. Briefly, Virtual Root is a feature that allows users to connect to either a Plan or Folder object (a Folder object is recommended). When connected this way, the user's scope is limited - regarding what they can see and access in the Object Navigation Pane and Instances views. Regarding the objects, users will see the contents of the connection point (child and nested child objects of the connection point). If you organize your objects as described above, it does make using a virtual root connection more viable, because the non-executing objects will be "in-scope" to the connection point (this is true, when using the above example image and connecting to the UsersGuideCaseStudies Folder). If all the non-executing objects are child objects of the connection point, they will be accessible to the end-user connecting to a virtual root.

 

Assume a user is connecting to the UsersGuideCaseStudies Folder using the virtual root feature. When they view a Job's Submission Queue, they will not see the connection point Folder name in the Submission Queue dropdown, but rather, they will see the child objects of the connection point. Since the Queue is stored in the Objects Folder, you see that Folder name followed by the Queue name. Observe the difference between the image below (connected to the virtual root) and the one above (when connected to the Scheduler root).

 

 

In this case “/Server1” is relative to our new virtual root UsersGuideCaseStudies. When a user is connected to a virtual root, that user cannot access any objects that are out-of-scope. By out-of-scope we mean that the objects are located at the same or higher path level of the connected Folder.

 

As an analogy, consider the SUBST command in Windows. “SUBST D:   C:\Test” creates a drive “D” that actually points to “C:\Test”. There is no capability that exists to address objects at a higher level than C:\TEST (for example, C:\ or C:\ANOTHER-TEST are inaccessible through D:). 

 

Consider this example. Suppose we placed “Server1” at the Job Scheduler root level and then connected into the system at <SchedulerName>/UsersGuideCaseStudies”. What would the Job's “Submission Queue” property look like then? The figure below depicts what would be displayed.

 

 

The notation “$” followed by path indicates that the specification is the true absolute path. While the original path specification will continue to work, it is inaccessible to the user who has connected to a virtual root, since the Queue is stored at the root level, which is a "higher" level and out of the user's scope.

 

Note, if you click on the ellipsis that allows you to access the properties of the Queue, you will receive an ActiveBatch error, as depicted in the image below. This is because the Queue is out-of-scope, and therefore you are not allowed to view its properties.

 

While visual indications are made when you access the system at a “virtual root” level, you can always select the root node of the Object Navigation pane - right click, then select Properties. You will see a subset of the Job Scheduler properties page with one important notation. Observe the Virtual Root item has a Value of /UsersGuideCaseStudies. You will only see this when connected to a virtual root.